reflow reasons/types
L. David Baron
I'm thinking of trying to simplify the reflow reason/type mechanisms by
replacing the current ones with:
Full
Resize
Descendant (for reflow reason only)
This is something that I think would be easier to translate into a dirty
bits system (which I've been thinking more about), along the lines of
what I've mentioned earlier.
Descendant is the equivalent of the old Incremental, and Full is the
equivalent of the old StyleChange.
The initial/full distinction is bogus and I remember seeing it break in
some cases where we move children into a new parent (e.g., {ib} or
:first-line) and the new parent translates a style change reflow to an
initial reflow and breaks the style change on the kids. We have
NS_FRAME_FIRST_REFLOW if we need it.
I'm planning to just try this and see what happens (if I have time
sometime soon).
-David
--
L. David Baron <URL: http://dbaron.org/ >
Boris Zbarsky
> I'm thinking of trying to simplify the reflow reason/type mechanisms by
> replacing the current ones with:
>
> Full
> Resize
> Descendant (for reflow reason only)
So the reason would be "Descendant" till we get to the target and then
get changed to the "type"?
Right now it looks like the "reason" identifies the thing that caused
the reflow to be triggered and the "type" identifies what type of reflow
is desired, with much confusion between the two. In the end, do we
really care about the reason, as long as we know what type of reflow we
have to do... The only reason to have "Descendant" is so that you know
to not do anything yourself unless the kids do, right?
> The initial/full distinction is bogus and I remember seeing it break in
> some cases where we move children into a new parent (e.g., {ib} or
> :first-line) and the new parent translates a style change reflow to an
> initial reflow and breaks the style change on the kids. We have
> NS_FRAME_FIRST_REFLOW if we need it.
Agreed. This will require fixing up some frames to deal, but should be
done.
-Boris